One of the most important aspects of a modern computing system is the interface between the human user and the machine. The earliest and most popular type of interface was text based; a user communicated with the machine by typing text characters on a keyboard and the machine communicated with the user by displaying text characters on a display screen. More recently, graphic user interfaces have become popular in which the machine communicates with the user by displaying graphics, including text and pictures, on a display screen and the user communicates with the machine both by typing in text-based commands and by manipulating the displayed pictures with the pointing device, such as a mouse.
Many modern computer systems operate with a graphic user interface called a "window environment" in which the main user interface object is the "window". In a typical window environment, the graphical display portrayed by the display screen is arranged to resemble the surface of an electronic "desktop" and each application program running on the computer is represented as one or more electronic "paper sheets" displayed in rectangular regions of the screen called "windows".
Each rectangular region generally displays information which is generated by the associated application program and there may be several window regions simultaneously present on the desktop with each window region representing information generated by different application programs. An application program presents information to the user through each window by drawing or "painting" images, graphics or text within the window region. The user, in turn, communicates with the application both by "pointing" at objects in the window region with a cursor which is controlled by a pointing device and manipulating or moving the objects and also by typing information into the keyboard. The window regions may also be moved around on the display screen and changed in size and appearance so that the user can arrange the desktop in a convenient manner.
There may be several types of windows associated with each application program--these windows include the main window, which is always present, and other windows such as "pop-up" windows which appear in response to a specific user or program action. Pop-up windows include a type of window called a "dialog" box which is a type of pop-up window that appears on the screen for a short duration of time and accomplishes a specific task, such as obtaining a file name or performing a selection. Simple applications may include only the main window, while complicated applications may use tens and ever hundreds of pop-up windows and dialog boxes. There are also windows, called palettes and panels that are always on the screen and utilized in conjunction with the main window. They typically float above the main window facilitating easy access to commands, colors or direct manipulation elements.
The windows, in turn, include other user interface objects such as, scroll bars which can be used to move or change the portion of the window which is displayed and menu systems that allow a user to select various commands and actions. In addition, window environments also typically provide "standard" user interface objects called "controls" which can be displayed in the windows and manipulated by the user. The standard objects allow all of the application programs which run with a given GUI to have the same "look and feel" and, thus, user learning time is generally reduced.
The standard objects can include push buttons which are generally rectangular areas of the window which are rendered to appear as a "three-dimensional" button. The push-button has built-in behavior which is controlled by the window system to change the screen appearance of the button so that the button appears to be "pushed in" when the button display area is selected. Other selection displays include "checkboxes" which can display a check mark or other indicia to indicate a selection and "radio buttons" which are a set of check boxes in which selection of one box deselects the other boxes in the set.
Other standard user interface objects include objects which display items. These displays include text display areas and graphics display areas. The text display areas may include a simple line of text which displays text but cannot be edited. More complicated displays include list boxes which display a scrollable list of either graphical or text items and drop-down list boxes which appear as a single line but expand to a list when a predefined area is selected. With list boxes and drop-down lists the user may be able to select items as well as manipulate the displays. Still more complicated display areas include edit areas which are rectangular areas that allow the user to edit text using predefined commands. Some window environments allow the users to design their own controls which may be combinations of existing controls or entirely new controls with custom behaviors. The graphic display areas can include user-designed bit map graphics, icons and customer user graphics.
In most windows systems, the overall behavior and appearance of the aforementioned windows and controls are determined by the portion of the operating system known as a "graphical user interface" (GUI) or the "graphical device interface" (GDI). Instead of an application program drawing and controlling the user interface object, the GUI system actually renders the interface object on the display screen and controls appearance changes due to user selection movement and manipulation. User manipulations of the object are communicated to the application program by messages that are sent from the GUI to the application program and the application program controls the interface objects by sending messages to the GUI.
Even though an application program does not actually control drawing of the interface objects, the application program must initially specify parameters such as the size, position and appearance attributes (such as colors) for each user interface object to the GUI so that the object can be initially rendered in the desired position with the proper appearance. In many windows environments, the user interface object parameters are stored in a "resource" file in which each user interface object is assigned an identifier and associated with a list of parameters for that object. During the normal application program development cycle, after the application program is written and compiled, the resource file is also compiled and the resource object file is "bound" to the object file of the application program. Thereafter, during the operation of the application program, a user interface object is drawn on the screen by making a function call to the GUI and including the resource file identifier as a parameter in the function call. The GUI then reads the resource file and extracts the necessary parameters to render the interface object.
The structure and format of the resource file are fixed by the GUI and it is possible for an application program developer to directly compose and edit the resource file. However, direct composition and editing of the file is extremely tedious since each interface object generally has many separate parameters, all of which must be included to properly render the object. In addition it is often very difficult to position the objects with respect to each other and compose and entire screen display simply by looking at the parameter lists for each object.
Accordingly, user interface objects are generally designed by means of a "resource editor" program. This latter program uses the contents of a resource file to generate displays of the user interface objects contained therein which displays appear on the display screen in the same manner as they would appear when drawn by the GUI as the application program is actually being run. The application program developer can manipulate the object displays and, in response, the resource editor program edits the resource file parameters to insure that the user interface objects will appear properly when drawn by the GUI.
While the resource editor approach works well with small to medium size projects, for large projects it becomes a bottleneck. A large development project may have hundreds, or even thousands, of user interface objects. In addition, many programmers may simultaneously be working on parts of a project or several different projects which, although separate, share user interface objects. If a single resource file is used for the entire project, then the normal development cycle of compile, link, test and debug results in the resource file being compiled over and over or worse, results in developers having to wait for the file to be free. If several smaller resource files are used, then some method must be used to insure that duplicated interface objects are kept up to date and that everyone is using the latest versions.
Further, the resource file/editor approach is not flexible. In particular, the resource editor is designed to work with a predefined set of user interface objects. If a new user interface object is designed, then the resource editor must be rewritten to accommodate this new object. Consequently, the conventional resource editor approach is a poor choice in flexible development environments such as object-oriented development environments which are designed to be easily extensible.
In addition, the traditional resource file/editor approach is not easily adaptable to multi-lingual environments where the text appearing in the user interface must be translated into a local language to allow the program to work in foreign countries. The normal manner of handling this problem is to consolidate all text strings in a separate "string table". Rather than coding a text string directly into program code, the corresponding text is inserted as an entry in the string table along with an identifier. The application program code uses the identifier to retrieve the appropriate string at run-time from the string table and the string is then displayed. Since most of the text is located in a single table, the task of translating the text into a local language is greatly simplified.
The string table approach suffers from the same problems as the resource file. First, a single string table becomes a bottleneck during the normal development cycles. Second, multiple string tables must be coordinated to avoid different text strings from being associated with the same interface object. In addition, although conventional string tables contain most of the text information for a development project, a significant amount of text still becomes embedded directly into the program. This latter text includes menu headings and menu option lines, text found on button faces, and miscellaneous text displays. Accordingly, the job of translating an application program into a new language still remains a tedious and time-consuming job. This remains true even if the text portions of some of the user interface objects have already been translated, since the remainder of the text must still be found and translated.
Accordingly, it is an object of the present invention to provide a user interface object archiving system which can manage user objects to insure consistency between various sections of a project or various projects which utilize common objects.
It is another object of the present invention to provide a user interface object archiving system which can easily accommodate newly-designed user interface objects without requiring a rewrite of the object editor.
It is still a further object of the present invention to provide a user interface archiving system which facilitates the translation of the text in an application to an alternative language.